The present invention is directed to data base systems, and more particularly to a technique which enables data to be efficiently retrieved with the use of views having complex definitions. Although not limited thereto, the invention is particularly concerned with the standard for relational data bases known as "Structured Query Language" (SQL) and the constraints imposed thereby. For further detailed information relating to this standard, reference is made to Date, A Guide To The SQL Standard (1987) and Date, A Guide To DB2 (1985).
In relational data base management systems of the type to which the SQL standard pertains, data is stored in the form of base tables. Each base table essentially consists of a series of fields which define columns of the table. Each row of the table comprises a single record, also referred to as a "tuple." For each row of data in a table, a counterpart of that data is physically stored in the data base. When the data base user accesses a base table, the appropriate portion of the stored data is retrieved and presented to him in the form of a table.
In addition to base tables, data can also be accessed by means of "views." In contrast to a base table, a view is a "virtual" table in that the table does not directly exist in the data base as such, but appears to the user as if it did. In fact, the view is stored in the data base only in terms of its definition. For example, a view might comprise a subset of a base table, such as those tuples of the table which have a predetermined value in a particular field. As another example, a view could comprise a join operation, e.g. union, of two or more tables, where these other tables can be base tables, other views or a combination of both.
In relational data base systems that comply with the SQL standard, desired information is searched for and retrieved by means of expressions known as queries. For example, if a table named "Employee" contains the fields "Name", "Dept", "Age" and "Salary", and a user desires to find the subset of employees who work in the toy department, the following query can be used:
______________________________________ SELECT Name, Salary, Age FROM Employee WHERE Dept = "Toy" ______________________________________
If it is known that the information produced by this query will be used several times, a view can be defined, to thereby avoid the need to reformulate the query each time the information is desired. A view named "Emptoy" which produces the same information can be defined by means of the following statement:
______________________________________ CREATE VIEW Emptoy (Name, Salary, Age) AS SELECT Name, Salary, Age FROM Employee WHERE Dept = "Toy" ______________________________________
With this view created, the original query would then become:
______________________________________ SELECT * FROM Emptoy ______________________________________
(where the character "*" is a universal character to designate all fields in the table or view). As can be seen, the prior definition of the view makes the query much easier to formulate.
In addition, this view can be the subject of a further query. For example, to obtain the salary of all employees named Johnson in the toy department, the following query can be entered:
______________________________________ SELECT Salary FROM Emptoy WHERE Name = "Johnson" ______________________________________
As noted above, the data which makes up the virtual table Emptoy is not actually stored as such in the data base. Rather, only the definition of the view is stored. Accordingly, when a query which references a view is entered, a process known as view decomposition is carried out to translate the query into an equivalent query which references only stored base tables. In essence, the view decomposition process comprises the steps of replacing the reference to the view in the query with the definition of that view. Thus, in the example given above, the query for obtaining the salary of the employees named Johnson in the toy department would be modified to produce the following equivalent query:
______________________________________ SELECT Salary FROM Employee WHERE Name = "Johnson" and Dept = "Toy" ______________________________________
As can be seen, the modified query refers only to base tables and fields within that table.
In principle, it should be possible for a query to reference any view defined by an arbitrary query, and to translate that query into an equivalent operation on the underlying base tables. In practice, however, the applicability of this procedure is quite limited because of restrictions imposed by the SQL standard. For example, a view labeled "Avgsal" can be defined from two base tables Dept and Emp. The table Dept contains the fields "Dno" (department number), "Dname", "Mgrname" and "Loc", and the table Emp contains the fields "Eno" (employee number), "Dno", "Salary" and "Jobtitle". The definition of the view Avgsal which describes a department by its department number, department name and the average salary of its employees could appear as follows:
______________________________________ CREATE VIEW Avgsal (Dno, Dname, Avgsalary) AS SELECT Dno, Dname, AVG(Salary) FROM Dept, Emp WHERE Dept.Dno = Emp.Dno GROUP BY Dno ______________________________________
A query that asks for the location of all departments whose employees have an average salary greater than $30,000 would require a join operation on the base table Dept and the view Avgsal and could appear as follows:
______________________________________ SELECT Loc FROM Dept, Avgsal WHERE Dept.Dno = Avgsal.Dno and Avgsal.Avgsalary &gt;30,000 ______________________________________
Unfortunately, the limitations of the view decomposition technique prevent the processing of this query. More particularly, the query cannot be processed because the WHERE clause contains reference to a virtual column Avgsalary which does not correspond to an existing column of a base table.
Basically, the translated form of an original query must always be a legal query itself. Thus, the applicability of view decomposition is limited to views which are relatively simple. Hence, it is desirable to provide a technique which enables views with a greater degree of complexity to be referenced in queries, and thereby expand the processing power of a database system.